Translation tools exist that allow a user to create a correspondence between the records and fields in two different specification formats (e.g., a source object and a destination or target object). For Example, MICROSOFT® BizTalk Mapper is a highly graphical tool that presents the user with both source specifications and destination specifications side-by-side and lets the user define transformations by drawing lines between records, fields, and functoids. Functoids perform operations that range from simple calculations to elaborate script functionality.
BizTalk Mapper uses an Internet standard called Extensible Stylesheet Language (XSL) Transformations (XSLT), which is a W3C standard or language for transforming Extensible Markup Language (XML) documents from one XML schema into another.
Thus, the BizTalk Mapper is used to define a structural transformation of a message from one format/syntax to another. A graphical user interface exists to represent a textual transformation language (e.g., XSLT) by providing a compiler for the visual representation. The Biztalk Mapper supports creation of XSLT without requiring any knowledge of that language (and, in fact, without ever showing the XSLT at all unless the user specifically is looking for it). This is desirable because message transformation is an application integration activity that is typically performed by business analysts and those not likely to understand the transformation language (XSLT) itself.
BizTalk Mapper supports a variety of mapping scenarios that range from simple, parent-child tree relationships to detailed, complex looping of records and hierarchies. When the mapping process is complete, a serializer component uses the specification to create a file format that can be recognized by a trading partner or internal application. BizTalk Mapper also includes a style-sheet compiler component that takes the visual representation of the map and creates an XSLT style sheet.
One of the difficulties of simplifying the XSLT definition using a graphical depiction is the fact that some of the power of XSLT does not lend itself well to graphical depiction at all. Similarly, XSLT transformations are not typically intended to create data so much as to move it from one hierarchical location to another. XSLT also has limited support for what is often referred to as “rich” transformation, modifying data as it is moved from source to target location using programming-like capabilities (e.g. UpperCase, etc.).
Moreover, one of the most time consuming parts of mapping is the process of ensuring that all fields are mapped. In many cases, this can amount to drudge work, where the mappings are known and obvious, but still require manual connection.
In view of the foregoing, there is a need for systems and methods that overcome the limitations and drawbacks of the prior art.